Repository navigation
Fix InstanceTraffic.combine overwriting last_ping with an older minute - #14146
Conversation
A segment carries the minute its span started, so the segment of a request that began minutes earlier can update an instance after its heartbeat wrote the current minute. combine copied that older last_ping, and the instance dropped out of the instance list queried with a time range starting after it. Keep the larger last_ping, as EndpointTraffic does since apache#14122.
wu-sheng
added
backend
|
Note, this is a small safeguard against out-of-order timestamps. Keeping the maximum fits the existing instance interval: earliest timeBucket, latest last_ping. |
|
The one red check, The same Helm post-install timeout happened on master at 217e2e6 in Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5.5. |
2 participants
Fix a service instance dropping out of the time-ranged instance list after a late update
InstanceTraffic.combinecopies thelast_pingof the incoming record, so a record carrying an older minute moveslast_pingbackwards. The heartbeat writes the current minute (ManagementServiceHandleruses the server clock), while a segment writes the minute its span started (RPCAnalysisListener). When the segment of a request that started at 14:21 arrives after a heartbeat at 14:25, the storedlast_pingbecomes 14:21, andlistInstanceswith a duration starting at 14:22 or later, which filters onlast_ping >= start, leaves the instance out until a newer record lands.This is the same cause #14122 fixed in
EndpointTraffic.combine; this change keeps the largerlast_pingthe same way.InstanceTrafficTestcombines a stored 14:25 with a 14:21 record and then a 14:30 one. Before the change it fails withexpected: <202003281425> but was: <202003281421>; after it passes, andEndpointTraffic*Teststill pass.CHANGESlog.Found by a defect-hunting pipeline I build and run (Dev-next-gen), using Claude Code with Anthropic's Claude Opus 5.5.